A typical web browser receives data from a web server that defines the appearance and rudimentary behavior of a web page for display on a client system. In a typical scenario, a user specifies a Uniform Resource Locator (“URL”), a global address of a resource on'the World Wide Web, to access a desired web site. Generally, the term “resource” refers to data or routines that can be accessed by a program. An example URL is “http://www.microsoft.com/ms.htm”. The first part of the example URL indicates a given protocol (i.e., “http”) to be used in the communication. The second part specifies the domain name (i.e., “www.microsoft.com”) where the resource is located. The third part specifies the resource (i.e., a file called “ms.htm”) within the domain. Accordingly, a browser generates an HTTP (HyperText Transport Protocol) request associated with the example URL to retrieve the data associated with ms.htm file within the www.microsoft.com domain. A web server hosting the www.microsoft.com site receives the HTTP request and returns the requested web page or resource in an HTTP response to the client system for display in the browser.
The “ms.htm” file of the example above includes static HTML (HyperText Markup Language) code. HTML is a plain-text authoring language used to create documents (e.g., web pages) on the World Wide Web. As such, an HTML file can be retrieved from a web server and displayed as a web page in a browser to present the rich graphical experience that users have come to expect while viewing information from the Internet. Using HTML, a developer can, for example, specify formatted text, lists, forms, tables, hypertext links, inline images and sounds, and background graphics for display in the browser. An HTML file, however, is a static file that does not inherently support dynamic generation of web page content.
In some circumstances, a web page may need to display dynamic content in a browser, such as a changing stock price or traffic information. In such situations, a server-side application program is typically developed to obtain the dynamic data and format it into HTML that is sent to the browser for display in a web page as the web page is updated.
Additionally, these same server side applications programs may be used in situations where the data is not strictly dynamic but where there are so many different values that may be displayed in a static web page that it would be impractical to create the required number of static web pages. For example, a trip planning page might display two calendars: one calendar for departure date and one calendar for return date. Rather than developing hundreds of static pages with every possible pair of calendar combinations, a server-side application program can dynamically generate the appropriate static page with the appropriate calendars displayed.
Many web pages allow the user to interact with the page displayed in the browser by selecting visual elements of the page. For example, in the above mentioned trip planning page, the calendar might allow the user to interact with it, by clicking on a day to select that date, or clicking on an icon to go forward or backward a month. In existing solutions, a browser will submit an HTTP request back to the server side application program. The HTTP request can include parameters encoded in the query string, as form post variables, or some other data format to describe client-side events or data (e.g., which control the user clicked on). For example, the parameters might include the date that the user selected in one calendar, along with the date currently displayed in the other calendar.
The communication of events and data back to the server is called a “post back” because the browser typically sends the request using an HTTP POST request. The serve side application program can process the HTTP request and generate the appropriate HTML code for web page with a newly computed calendar to reflect the user's action for transmission to the client in an HTTP response. Thereafter, the resulting document is transmitted to a client system in an HTTP response, where it is displayed in the browser as a web page that shows the updated calendars.
Developing a server-side application program can be a complex task requiring not only familiarity with normal HTML coding that is used to layout a web page, but also with the programming basics, including one or more programming languages (e.g., C++, Perl, Visual Basic, or Jscript), and the HTTP protocol, including how data is sent between the browser and the server. Web page designers, on the other hand, are frequently graphics designers and editors, who may lack programming experience. Furthermore, simplifying complex web page development can speed the development of new web content by any developer.
Generally, development of a custom server-side application program also requires tremendous effort, so much, in fact, that developers are often disinclined to attempt it. Not only must a developer understand the HTML code that must be generated to display a desired web page, but the developer must understand how user interaction and client data from the web page will result in post back operations. It is desirable, therefore, to provide a development framework that allows a developer to dynamically create and process a web page with minimal programming.
One approach to minimize the programming requirements of dynamic web page generation has been the Active Server Page (ASP) framework, provided by Microsoft Corporation. An ASP resource typically includes Visual Basic or Jscript code, for example, to process an HTTP request that specifies the ASP resource as the desired resource and, thereafter, to generate the resulting HTML code in a HTTP response to the client. Furthermore, an ASP resource may reference pre-developed or third party client-side library components (e.g., client-side ACTIVEX controls) to ease a given application programming effort. However, in the current server-side application frameworks, the programming required to dynamically manage client-side user interface elements (e.g., text boxes, list boxes, buttons, hypertext links, images, sounds, etc.) within server-side applications can still require sophisticated programming skills and considerable effort. An unanswered problem exists in properly encapsulating programming required to process user interface elements, including handling postback events, so as to allow the web page developer to focus on other aspects of the web page.